I'm not convinced. This would be hardcoded into every compiler while this is a configuration issue, and it's already handled by CRYSTAL_CONFIG_PATH and CRYSTAL_PATH.

I think the makefiles should export CRYSTAL_CONFIG_PATH=$PWD/src:lib (when unset), and call sites should just configure CRYSTAL_PATH. Some helpers calling to crystal already do it.

CRYSTAL_CONFIG_PATH is for configuring the stdlib source path for packaging. We could customize it for development builds to CRYSTAL_CONFIG_PATH=$$ORIGIN/../src, but then it wouldn't work when installed at /usr/share/crystal/src, for example. We'd need separate configuration for production builds.
You can either have a compiler build that picks up the local path, or one that is ready to be installed in a system path (or wherever).
Maybe, that's fine. But right now you can build a compiler, test it (with this patch, using .build/crystal), and then install it. The automatic discover just works.

Without automatic discovery, .build/crystal would not have any usable default configuration for CRYSTAL_PATH. The CRYSTAL_CONFIG_PATH value doesn't work because it's not in an install location yet.

Requiring explicit configuration is much more inconvenient compared to bin/crystal.

I wonder if anybody's using the install target to be honest. Distributions merely set CRYSTAL_CONFIG_PATH (e.g. alpine, debian, homebrew, ...).

Does that matter? I don't think the usage makes much difference whether you run make install or install .build/crystal $out/bin/crystal 🤷

Yes, if nobody is using the install target and instead configure CRYSTAL_CONFIG_PATH, then there's little point for the Makefile to keep using $$ORIGIN/../share/crystal/src by default.

I think they are two independent dimensions: Using make install and relying on the default CRYSTAL_CONFIG_PATH are not directly related.
There are use cases involving either one or both of them.